As the complexity of software applications increases, the significance of an optimized library serving commonly used operations called from an application has become more and more important. For example, users may demand a faster rendering speed to support high resolution or near life graphic effects when playing an interactive computer game. Usually, a static non-optimized code library is available for an application to link during link time. These static libraries are often built during build time. Most static libraries are not optimally compiled to consider run-time states from calling applications because such states are not available during build time. In some cases, there may be too many possible run-time states and hence it may be impractical to create optimally compiled library routines.
Although some library routines may be optimally compiled on request during run time, such optimizations are typically performed without regard to the number of times an optimized library routine will be called by an application. This is especially true for operations during application start up. However, optimized library routines for supporting application start up tasks may be called only once or twice in the entire application life cycle.
Therefore, computing resources spent for run-time code optimization may be wasted. Additionally, an application may take more time optimizing a run-time library code than directly executing a corresponding static version. As a result, users tend to experience glitches in overall system performance.